home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
lanman
/
lanman-minutes-89feb.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
5KB
|
167 lines
CURRENT_MEETING_REPORT_
Reported by Amatzi Ben-Artzi/ 3Com
Minutes of February 22, 1989
The Lan Manager MIB working group met Wednesday, 2/22/89 in Sunnyvale,
CA for our first meeting. The meeting was very productive and generated
a long list of output and action items. Below is a summery of the
meeting and major decisions reached.
The minutes cover seven topics:
1. Introduction
2. The Group's Objectives
3. To Proxy or Not?
4. Initial Documents and Editors
5. Relationship to the MIB WG
6. Mailing List
7. Timetable
Introduction to the Lan Manager.
Amatzia gave a short introduction on the Lan Manager. The emphasis is
on the management interoperability issues between the Lan Manager as a
standard in the workgroup environment and the standards being developed
in the ``enterprise" environment. As both are based on the TCP/IP it is
important that they can cooperate. Microsoft offered to provide a more
extensive overview of the LanManager if people will find it useful.
Please send me feedback on this one!!
Group's Objective
The objective of the group is to define the MIB (and relevant related
mechanisms) needed to allow management overlap between the workgroup
environment (Lan Manager based) and the enterprise environment (based on
TCP/IP management).
We found that it translated into four basic areas:
1. Define a set of management information out of the existing Lan
Manager objects to allow for useful management from a TCP/IP based
manager.
2. Define extensions to the TCP/SMI where appropriate.
3. Develop requirements for additional network management information,
as needed, and work to extend the Lan Manager interfaces to support
such information.
4. Define the mechanisms of exchange of management information between
clients and servers so that proxies can be developed.
1
Proxy or Not?
We concluded that the manager need to have access to the management
information in every client in a direct way. It amounts to the
following:
o A client may have a Management/TCP stack.
o A client may be supported by a server that acts as ``proxy'' on his
behalf.
o The manager need not be aware of which one of the techniques above
is being used in the workgroup.
However, we recognized that in the proxy mode, the server may have two
types of objects: server resident, and client resident. For the second
type, a server-client mechanism has to be developed to allow the
implementation of a proxy.
Initial Documents and Editors
The following documents have been identified as needed. Initial editors
were also selected.
o SMI Extensions: Pranati Kapadia, HP
o MIB Objects: Jim Greuel, HP
o NDIS Extensions (not assigned)
o Transport APIs for NM Information access (not assigned)
o Client-Server management protocol (Amatzia Ben-Artzi, 3Com)
Relationship to the MIB group
A real objective of this MIB group is to work under the ``BIG'' MIB
group. One implication was that the MIB specification should follow the
1066 RFC (specifying all attributes as ``objects'') with an appendix
that actually describe the containment relationship (Same technique that
was used in the CMOT RFC to re-state the supported MIB)
A big question mark is SMI. Can we live with the guideline of ``no SMI
extensions'' ? We shall address it when the first required extension
shows. We do know, however, that EVENTS (or alerts, or alarms) are a
big issue, but we where not sure if this was an SMI issue or what.
We also feel very strongly that the recommendation of the previous MIB
group should be followed: Lan Manager should be assigned a number of
the MIB (Like TCP, IP, or CMOT) and define it objects under this branch.
Then, bring them forward to the larger group for discussion and
approval. ONLY EXPERIMENTAL OBJECTS SHOULD BE PLACED UNDER THE
EXPERIMENTAL BRANCH.
2
The whole branch is OPTIONAL, so people who don't implement it do not
have to worry about conformance. It seems like we would want, for
simplicity of conformance, at least initially, to say: the branch is
optional, but if you implement it, it is ALL mandatory. The target is
roughly 20 - 30 objects initially.
Mailing list
Welcome a new mailing list:
LanManWG@spam.istc.sri.com
As usual, there is also a LanManWG-request.
Timetable
March 17: First draft proposal for MIB objects in the mail.
March 31: Comments are due back to the editor
April 11-14: IETF meeting. We shall meet sometime there to discuss the
proposed draft (currently planned as a half-day meeting)
Thanks to all the participants for a very effective meeting.
Attendees
aguilar@istc.sri.com SRI
jimg@hpcnd.hp.com H-P
...!ucbvax!mtxinu!excelan!ramesh Excelan
...microsoft!henrysa Microsoft
geo@ub.com Ungerman-Bass
kapadia@hpda.hp.com H-P
davep@esd.3com.com 3Com
jcham@mbunix.mitre.org Mitre
Hunter@nmfecc.arpa Laurence Livermore Lab
...!ucbvax!mtxinu!excelan!pramod Excellan
jonab@cam.unisys.com Unisys
kzm@twg.com The Wollongong Group
amatzia@spd.3com.com 3Com
3